~4Dgifts/toolbox/src/swtools/KrnlCrashDBG README type: man -d crpt.1 to view the man page for the crash report script To generate a crash report: cd /var/adm/crash (/usr/adm/crash in IRIX 4.*) Example: If you have a unix.1 and a vmcore.1.comp, it's easiest just to run crpt with "1" as the arguement. Also, you'll have to be root to read the core files or you'll have to change the permissions on the files. % su # crpt 1 README for crpt This "crpt" script hails from the INSIGHT system now available thru the customer support division at sgi. the following problem description is the kind of thing crpt can help to pinpoint. (If nothing else, do what the man page below describes and then call up the Technical Assistance Cente at 1-800-800-4744 and the data generated by running the crpt script can help the TAC people help you solve the problem you're having.) >| The system is an 4D/80GT (originally upgraded from a 4D/70GT). After >| running the power-on diagnostics, the system spits out the following: >| >| PANIC: KERNAL FAULT >| pc: 0x8001f73c, ep: 800e43c8, exc code 28 databus error >| bad address 0x1000d0c8, cause: 0x3000041c <ce1ce0 ip3> >| sr: 0xf804 <im6, im5, im4, im3, iep> >| >| After all of that, it does a dump and asks for a reset. >| >| We suspect that it is a hardware problem with one of the graphics boards, >| but were wondering if someone out there in SGI land could narrow it down >| to a specific board. Needless to say, the system is not under maintenance, >| and some of the boards are refurbished and not purchased directly from SGI. >Your best bet is to run dbx or dis on that part of the kernel (0x8001f73c), >the routine name might help spot the problem. Doing a full backtrace >on the save crash file (in /usr/adm/crash) would be even more helpful; >the output from uname -a and/or versions -vn eoe1 would help us know >which OS release you have. If you are able to boot, you can run the following "crpt" script which will do all of the things just mentioned automatically - INSIGHT(1) UNIX System V INSIGHT(1) NAME crpt - Kernel core file report generator SYNOPSIS /usr/sbin/crpt -n [unix.N] [vmcore.N] or [N] DESCRIPTION crpt generates a report from kernel core files that can aid your support provider in determining the cause of a system crash. The report is saved in current directory as "Crash_N.rpt" (Where "N" is the number of the dump file as specified by /usr/adm/crash/bounds). When a system crashes, it saves the contents of physical memory and a copy of the kernel that was running. savecore places these files in /usr/adm/crash. If your system has crashed and you do not have unix.N and vmcore.N in /usr/adm/crash, make sure your primary swap space on your system disk is at least as large as your physical memory and that you have at least that much free space in your /usr partition (see savecore(1M)). Save unix.N and vmcore.N to tape in case indepth debugging is required. Usually only a kernel expert with access to the SGI source code can accurately debug these core files. crpt drives the dbx debugger through the basic steps a kernel expert would start with when debugging a system crash. The dbx(1) debugger must be installed for crpt to run. The report can be included in a call logged through electronic services or emailed or faxed to your local support provider. crpt provides the following information: 1) Report System Info: -The full path of the given core files -Output of the utsname data structure to provide system information: If the script is run on the crashing system, it will provide additional hardware and software information. The output from "hinv" and "versions -b" will be incorporated into the script. 2) Formatted output from the kernel's error buffer. This buffer contains errors messages that are flushed to the system's error log (/usr/adm/SYSLOG), but this buffer is often not flushed when the system crashes. 3) Print the name of the program that was running Page 1 (printed 10/11/92) INSIGHT(1) UNIX System V INSIGHT(1) at the time of the crash and the process id of that program. 4) Print a kernel stack trace on the current process id with the "print_exception_frame" variable set. This will help trace the functions called which lead up to the crash. If there was an exception, the contents of the exception frame (exception context) will be printed out above the function which trapped into the kernel. 5) Disassemble the code surrounding the exception program counter. This will output the name of the routine the system crashed in and the line number in the source code. 6) Output for 'netstat -m' can be viewed by the -n option. 7) Output for 'netstat -n' can be viewed by the -n option. OPTIONS Command line options are described below. -n The -n option turns on netstat -m and -s reports (see netstat(1)). SEE ALSO savecore(1M), dbx(1), netstat(1)
Documentation
Reference